When running our nightly book update job, we assume the default branch
for the progit2 repo (and any translation repo) is "master". This may be
changing in the future. Best case that would cause us to stop getting
updates. Worst case it may actually cause subtle bugs, since we pull the
tree sha by asking for "HEAD".

Note that we can't just swap out "HEAD" here. GitHub's refs API expects
us to ask for "heads/foo" or "tags/foo", and passing "HEAD" seems to
imply "heads/HEAD". I didn't check if that's Octokit being clever, or is
how GitHub's API behaves, but either way it doesn't work.

We can hack around it by using the "commit" endpoint, which takes any
resolvable name. And since "HEAD" always has to point to a commit (by
Git's rules), we're in no danger of being confused by another object
type. It does get us a bit of extra information we don't care about (we
just need the sha, not the actual commit message), but the extra cost
should be negligible in practice.

When we index book content, we use the sha1 of the HEAD commit as a
cache key to see whether anything has been updated. But we fetch the
tree content by asking for HEAD separately. It's unlikely, but the
repository could be updated between the two, meaning we'd store a
mis-matched cache key (and because we get the tree first, we'd be stuck
with the old data under the new key, and thus wouldn't even notice on
the next run).

We can fix this by getting the commit first, and then using the tree
sha1 it mentions, which is atomic. This is easy now that we're grabbing
the whole commit (and this also matches how we do documentation
indexing).

When there are no tags, we look for documentation in the hard-coded
master branch. This is unlikely for git.git, but presumably triggers for
translation repos. We should be more flexible and just use HEAD in this
case, which will do the right thing if the translation repos switch
their default branch.

Note that we don't to do anything clever here like we did for the
"book2" case. We're already using the commit API for the remote index,
so we're free to just look up the name "HEAD". And likewise the local
case is just running Git commands, so that name is fine.